FIG. 1 is a network structure of an LTE (Long Term Evolution) system, the related art mobile communication system. For the LTE system, which has evolved from the existing UMTS system, basic standardizations are ongoing in the 3GPP.
An LTE network can be divided into an E-UTRAN (Evolved UMTS Terrestrial Radio Access Network) and a CN (Core Network). An E-UMTS includes a terminal (or UE (User Equipment)), a base station (eNB (Evolved NodeB), and an access gateway (aGW). The access gateway may be divided into a part that handles processing of user traffic and a part that handles control traffic. In this case, the access gateway part that processes the user traffic and the access gateway part that processes the control traffic may communicate with each other by using a new interface. One or more cells may exist in a single eNB. An interface for transmitting user traffic or control traffic may be used between eNBs. The CN may include the access gateway and a node or the like for user registration of the UE. An interface for discriminating the E-UTRAN and the CN may be used.
FIG. 2 shows an exemplary structure of a control plane (C-plane) of a radio interface protocol between the UE and the E-UTRAN based on the 3GPP radio access network standards. FIG. 3 shows an exemplary structure of a user plane (U-plane) of the radio interface protocol between the UE and the E-UTRAN based on the 3GPP radio access network standards.
The structure of the radio interface protocol between the UE and the E-UTRAN will now be described with reference to FIGS. 2 and 3.
The radio interface protocol has horizontal layers comprising a physical layer, a data link layer, and a network layer, and has vertical planes comprising a user plane (U-plane) for transmitting data information and a control plane (C-plane) for transmitting control signals. The protocol layers in FIGS. 2 and 3 can be categorized as a first layer (L1), a second layer (L2), and a third layer (L3) based on three lower layers of an open system interconnection (OSI) standard model widely known in the communication system. The radio protocol layers exist as pairs between the UE and the E-UTRAN and handle a data transmission in a radio interface.
The layers of the radio protocol control plane of FIG. 2 and those of the radio protocol user plane in FIG. 3 will now be described as follows.
The physical layer, the first layer, provides an information transfer service to an upper layer by using a physical channel. The physical layer is connected to an upper layer called a medium access control (MAC) layer via a transport channel. Data is transferred between the MAC layer and the physical layer via the transport channel. The transport channel is divided into a dedicated transport channel and a common channel according to whether or not a channel is shared. Between different physical layers, namely, between a physical layer of a transmitting side (sender) and that of a receiving side (receiver), data is transferred via the physical channel.
The second layer includes various layers. First, a medium access control (MAC) layer serves to map various logical channels to various transport channels and performs logical channel multiplexing by mapping several logical channels to a single transport channel. The MAC layer is connected to an upper layer called a radio link control (RLC) layer by a logical channel. The logical channel is divided into a control channel that transmits information of the control plane and a traffic channel that transmits information of the user plane according to a type of transmitted information.
An RLC (Radio Resource Control) layer, the second layer, segments or concatenates data received from an upper layer to adjust the data size so as for a lower layer to suitably transmit the data to a radio interface. In addition, in order to guarantee various QoSs required by each radio bearer RB, the RLC layer provides three operation modes: a TM (Transparent Mode); a UM (Unacknowledged Mode); and an AM (Acknowledged Mode). In particular, the RLC layer operating in the AM (referred to as an ‘AM RLC layer’, hereinafter) performs a retransmission function through an automatic repeat and request (ARQ) function for a reliable data transmission.
A packet data convergence protocol (PDCP) layer of the second layer performs a function called header compression that reduces the size of a header of an IP packet, which is relatively large and includes unnecessary control information, in order to efficiently transmit the IP packet such as an IPv4 or IPv6 in a radio interface having a narrow bandwidth. The header compression increases a transmission efficiency on a radio interface by allowing the header part of the data to transmit only the necessary information.
The RRC layer located at the lowermost portion of the third layer is defined only in the control plane, and controls a logical channel, a transport channel and a physical channel in relation to configuration, reconfiguration, and the release of radio bearers (RBs). Here, the RBs refer to a logical path provided by the first and second layers of the radio protocol for data transmission between the UE and the UTRAN. In general, the configuration of the RB refers to the process of stipulating the characteristics of a radio protocol layer and a channel required for providing a particular data service, and setting the respective detailed parameters and operation methods.
Hereinafter, the PDCP layer will now be described in detail. The PDCP layer is upwardly connected with the RRC layer or a user application, and downwardly connected with the RLC layer. In FIG. 4, the left side shows the structure of functions of the transmitting PDCP entity and the right side shows the structure of functions of receiving PDCP entity. The left transmitting side structure shows operations applied to a PDCP SDU when the PDCP layer receives the PDCP SDU from an upper entity, and the right receiving side structure shows operations applied to a PDCP PDU when the PDCP layer receives the PDCP PDU from a lower entity.
The PDCP are used for both the user plane and the control plane, and some functions of the PDCP are selectively applied according to a used plane. Namely, as shown in FIG. 4, the header compression function is applied only to data of the user plane, while an integrity protection function is applied only to data of the control plane.
A data processing procedure performed by the transmitting PDCP entity at the left side in FIG. 4 will now be described.
S1: The PDCP layer assigns a sequence number to a received PDCP SDU.
S2: If an established RB is an RB of a user plane, the PDCP layer performs header compression on the PDCP SDU.
S3: If the established RB is an RB of the control plane, the PDCP layer performs integrity protection operation on the PDCP SDU.
S4: The PDCP layer performs ciphering on data blocks generated according to the results of the step S2 or S3.
S5: The PDCP layer configures a PDCP PDU by attaching a proper header to the ciphered data blocks, and delivers the configured PDCP PDU to the RLC layer.
A data processing procedure performed by the receiving PDCP entity at the right side in FIG. 4 will now be described.
S6: The PDCP layer removes the header of the received PDCP PDU.
S7: The PDCP layer performs deciphering on the header-removed PDCP PDU.
S8: If the established RB is an RB of the user plane, the PDCP layer performs header decompression on the deciphered PDCP PDU.
S9: If the established RB is an RB of the control plane, the PDCP layer performs an integrity verification operation on the deciphered PDCP PDU.
S10: The PDCP layer delivers data blocks, namely, PDCP SDUs, which have been received through step S8 or S9, to an upper layer. If the established RB is an RB of the user plane, the PDCP layer performs reordering as necessary, and delivers the same to an upper layer.
The header compression performed by the PDCP layer will now be described. The header compression is reducing the size of a header based on the fact that an IP header of each IP packet belonging to the same packet stream is not mostly changed. Unchanged fields are stored in the form of context in a compressor of the transmitting side and in a decompressor of the receiving side, and when context is formed, only changed fields are transmitted to thereby reduce the overhead of the IP header. At an initial stage of the header compression, the compressor transmits a full header packet to form context with respect to a corresponding packet stream, so there is no gain with the header compression. But, after the context is formed in the decompressor, the compressor can transmit only a compressed header packet, so its gain is remarkably increased.
An ROHC (Robust Header Compression), a typical header compression scheme used in the LTE system, is used to reduce header information of a real time packet such as an RTP (Real-time Transport Protocol)/UDP (User Diagram Protocol)/IP (Internet Protocol). Here, the RTP/UDP/IP packet refers to a packet with relevant headers which have been added as data from an upper layer passes through an RTP, a UDP and an IP. It includes various header information required for the data to be transferred to a destination via the Internet and recovered. In general, as for the header size of the RTP/UDP/IP packet, the IPv4 (IP version 4) has a header size of 40 bytes and the IPv6 has a header size of 60 bytes. When the headers are compressed by using the ROHC, the 40 or 60-byte headers are reduced to 1 to 3-byte headers, obtaining remarkable gains.
FIG. 5 shows a change in a header size of a packet formed according to the ROHC. Specifically, FIG. 5 comparatively shows the change in the header size of the general RTP/UDP/IP packet and the change in the header size with the ROHC applied. When a packet stream is transmitted first, because context is not formed yet in the compressor of the transmitting side and in the decompressor of the receiving side, so a full header is transmitted to form context. When the full header is transmitted to a degree, context is formed, and thus, a compressed header can be transmitted. In this respect, the context may be damaged due to a loss or the like of packets midway, so it is required to transmit the full header at proper intervals. In general, the full header includes additional information to form the context, so it is slightly larger than a normal header.
The security function performed by the PDCP layer will now be described. As described above, the security includes two functions of ciphering and integrity protection. In the both functions, codes that vary for each packet are generated, with which original data is ciphered or checked for its integrity.
The codes that vary for each packet are generated by using a PDCP SN (Sequence Number) added to a header of each PDCP PDU, and one of code generation factors is COUNT. The COUNT has a length of 32 bits, of which the least significant bit (LSB) includes a PDCP SN and the other remaining most significant bits (MSB) include an HFN (Hyper Frame Number). The length of the PDCP SN is 5, 7 or 12 bits, namely, different for each RB, so the length of the HFN is different for each case as 27, 25 or 20 bits.
Ciphering is performed in a way as shown in FIG. 6. The transmitting side generates ciphered data by covering a code which is changed for each packet, namely, MASK, on original data. Here, covering of the MASK refers to performing XOR on the original data and the MASK by bits. When the thusly ciphered data is received, the receiving side covers the MASK again on the ciphered data to decipher it. Here, the MASK has a length of 32 bits and is generated from various input factors. In particular, in order to generate a different value for each packet, COUNT is generated by using a PDCP sequence number different for every PDCP PDU, and the generated COUNT is used as one of MASK generation input factors. Besides the COUNT, the MASK generation input factors include a ‘bearer’, an ID value of a corresponding RB, a ‘Direction’ having an upward or downward value, a ‘CK (Ciphering Key)’ exchanged by the terminal and the network in establishing an RB, or the like.
In addition, the integrity protection is performed in a way as shown in FIG. 7. Like the ciphering process, in the integrity protection process, a code, namely, ‘MAC-I (Message Authentication Code-Integrity)’, by using a ‘COUNT’ using the PDCP SN, a ‘Bearer’, an ID value of an RB, a ‘Direction’ having an upward or downward value, an ‘IK (Integrity Protection Key)’ exchanged by the terminal and the network in establishing an RB, or the like. Here, a difference from the ciphering process as shown in FIG. 6 is that the generated ‘MAC-I’ is not XORed with original data but attached to a PDCP PDU as shown in FIG. 7. When the receiving side receives the MAC-1-attached PDCP PDU, it generates an XMAC-I by using the same input factor as that used in the transmitting side and compares it with the MAC-I attached to the PDCP PDU. If the two values (namely, XMAC-I and the MAC-I attached to the PDCP PDU) are identical, it is determined that data has integrity, whereas if the two values are different, it is determined that data has been changed midway.
For some reasons, the MASK or the MAC-I of the transmitting side and the receiving side may be changed to cause an error in ciphering or integrity protection. The main reason for the MASK or the MAC-I to be changed is because HFN, the MSB of the COUNT, is changed. This occurs when numerous PDCP SDU are lost. The reason is because the MSB of the COUNT is HFN and the LSB of the COUNT is SN and if the PDCP SN reaches a maximum value, it returns to zero (0) and one HFN, the MSB, is increased. Namely, if PDCP SDUs are lost as many as to wrap around a PDCP SN space, de-synchronization of HFN occurs. For another reason, there may be an error that cannot be found even with a CRC (Cyclic Redundancy Code) inspection at a lower layer, and in this case, if the PDCP SN value is not within a valid range, HFN de-synchronization may occur.
When the HFN de-synchronization occurs, security fails. Thus, although the receiving side receives data, it cannot restore the original data, causing a problem that the receiving side continuously discards received data.
With this problem arising, the RB of the user plane and the RB of the control plane will be separately described.
First, in case of the RB of the user plane, received PDCP PDUs are deciphered and subjected to header decompression. At this time, if the PDCP PDUs are deciphered with an erroneous MASK, an error occurs continuously in the process of header compression, so the receiving side continuously discards the received PDCP PDUs.
Second, in case of the RB of the control plane, received PDCP PDUS are deciphered and subjected to integrity verification. If the PDCP PDUs are deciphered with an erroneous MASK or compared with an erroneous XMAC-I, errors continuously occur in the process of integrity verification, so the receiving side continuously discards the received PDCP PDUs.
This problem arises because a function of detecting HFN de-synchronization is not currently provided. As a result, once HFN de-synchronization occurs, it cannot be recovered, and the received PDUs since then have an error and thus continuously discarded.